Cracking 1

home *** CD-ROM | disk | FTP | other *** search

/ Cracking 1 / Cracking I..iso / Tools / Ostatní / aPLib v0.26b / examples / 16bit / HISTORY.TXT < prev next >

Wrap

Text File | 2001-12-15 | 16.8 KB | 379 lines

Porting aPLib decompresion routines by Jibz to 16 bits by METALBRAIN I haven't Internet conexion at home, so I can only connect from my University from Monday to Friday (only a short while in the morning, except Mondays, when I can also connect from 14:00 to 16:00), and some weekends from a friend's house (in summer is much worse). 28-10-98 to 12-10-98 I wanted to use aPLib v0.17b in my small game KOM, but all code is 32 bit, and KOM is a 16 bit project, so after several failing tests, I started writing 16 bit version of NASM assembly routines, cleaning all C connection protocol code and replacing string instructions and those that accessed memory through [esi] and [edi] with 16 bit emulation routines. I started putting them in smalls programs with fixed names for infile and outfile. After fixing a bug, they started to work. Then I got aPLib v0.18b, and updated my routines, and kept improving my test programs. Then finally came out aPlib v0.19b, so I updated my routines once again, and started to work more seriously, in order to offer my 16 bit port to Jibz. 14-11-98 Saturday Finally write a depacker capable of reading filenames from arguments. Infile can't be greater than 64Kb, and no test is made about memory, so if outfile is too big, it could collapse memory. My deppacker broke a file, and I couldn't find any bug on it. I made some tests and found out a bug in aPPACK itself. Oops. It also happens to previous versions. Jibz must be informed about it... 15-11-98 Sunday Cleaned the code a bit, eliminating some redundances. 16-11-98 Monday > I send Jibz first version of DEPACK and DEPPACK (948 bytes), and also tell him about aPPACK bug. 20-11-98 > Friday I got response from Jibz. He has found a bug in my routines, and he has optimized both DEPACK and DEPPACK a lot. I look at his code and feel really dumb. Some optimizations are so obvious... 22-11-98 Sunday I make first version of DEPPTINY. It's the same that DEPPACK, but without error nor usage messages. My first goal was to make it under 700 bytes (that was the size of the tinyest decompressor I knew before mine arrived), and as firstly I got it in 519, I played a bit to make it under 512 bytes (just one diskette sector). It ends up being 507(?) bytes long. 23-11-98 Monday > I send Jibz first version of DEPPTINY (507). At home I start coding next DEPPACK version, featuring use of all available memory to be able to uncompress any file which fits in low memory. 24-11-98 > Tuesday Jibz sent me a very optimized version of DEPPTINY (437). I can't believe my eyes. He wiped away 70 bytes!. I'm really amazed. And code is also cleaner, as he removed my dirty self-modifying code trick. I study his optimizations. Curious. He got rid of most variables. I look at the code and I'm able to clean 6 bytes from it. Now I feel great, my spirit rises and continue coding v0.2 of DEPPACK, but I can't get it working. 25-11-98 Wednesday > I send Jibz my optimization of DEPPTINY (431) and I asked him about my problem (thought I wasn't too clear about it). In the evening I study the code debugging it and fix my problem alone, with another dirty self-modifying trick. 26-11-98 > Thursday > I recieve Jibz's last work on DEPPTINY. I send him the very first version of DEPPACK v0.2 . At home, I look his DEPPTINY. Incredible!. He did it again! He killed 32 more bytes, leaving it in 398. Now some optimizations are really weird (such as order modification), but they work perfectly. 27-11-98 Friday to 29-11-98 Sunday I port some optimizations from last DEPPTINY to DEPPACK. I think he'll send me something next Monday, so I put NASM, aPACK, and some test files in my diskette, together with last DEPPACK. 30-11-98 > Monday > As I expected, Jibz has played with DEPPACK v0.2, optimizing it (he cleaned 3 bytes from DEPACK core) and has eliminated my self-modifying part (he really seems to hate them), but he hasn't implemented optimizations from last DEPPTINY, leaving them to me. Easy work, as it was already done. I spent half an hour with it and apply his last optimizations on my last version of DEPPACK (876), and send it back to him. 1-12-98 Tuesday I apply the optimization of the core to DEPACK and DEPPTINY. Works perfectly, and now it's only 395. 4-12-98 Friday I haven't recieved nothing yet, but I can see in his page that he's working in aPLib v0.20b. A long weekend awaits me, because there's no class next Monday and Tuesday. 6-12-98 > Sunday > I spent morning with a friend, and I could connect a little while. The response was there, so I took it. He tells me he's porting my routines to 16 bit C compilers, Borland ones are working and others are on the way. In the afternoon I look carefully last optimizations applied to DEPPACK (871): very instructive. They save a lot of bytes to uncompressed program, but after compresion he only won 6 bytes. I feel inspired and remove 7 bytes to uncompressed program, that become a gain of 16 bytes after aPACK compression. I feel very proud because one of the bytes I've killed was inside DEPACK core, so in the evening I send Jibz the whole pack from other friend's home: DEPACK, DEPPACK (855) and DEPPTINY (394). I thought they were going to be last optimizations before aPLib v0.20b release, but I was completly wrong. 14-12-98 Monday I've finished classes today, and there's been no feedback from Jibz yet, but I must go to University on Wednesday and Friday. Managed to cut 2 bytes from DEPPTINY. 15-12-98 Tuesday Got an idea: Cleaned 4 bytes from DEPPTINY and 2 from DEPPACK. 16-12-98 Wednesday > Got another idea: Cleaned 2 bytes from DEPACK core, so I send him again the whole package: DEPACK, DEPPACK (851), and DEPPTINY (386), not knowing if it will be there in time or not... 18-12-98 Friday Went to University, but computer rooms where closed. AAAAAARGH! 20-12-98 > Sunday Finally could connect, and catch Jibz's response. A new smaller version of aPACK leaves DEPPACK in 815 bytes. Great! I cut 4 more bytes from DEPPTINY and 2 from DEPPACK. Start coding DEPPACK 0.3b, capable of decompressing files of any size. I thought that "57300 bytes lookback" meant that only 57300 previous bytes were needed to unpack, but it I tried to use 64K and it didn't work at all. I spent the night trying to find bugs, and was not sure if it was possible to do what I wanted to do. At 5 a.m., tired and frustraded I leave it for impossible. 21-12-98 Monday I debug the depacking of some files to see the values it can take. I set the limit in 128K and finally progressive-write got running! I make progressive-read (much easier), and test the resultant DEPPACK v0.3 in some extreme files. I fix some bugs and down the limit to 96K, and it still works. I make the DEPPTINY v0.3 from this, but it's too big, and can't get it under 512 bytes, so I'm leaving it with 582 bytes. 22-12-98 Tuesday I clean the code a little, eliminate all self-modifying parts and optimize a bit. As DEPPTINY v0.3 can't fit a diskette sector, I make DEPPTINY v0.2, and it's 439 bytes long (the old 382 bytes long DEPPTINY was still first version, with 64K infile limit). 23-12-98 Wednesday > Fixed one small bug. I'll send him new versions of DEPPACK v0.3 and DEPPTINY v0.2 and v0.3 7-01-99 Thursday Back to classes, computer rooms closed due to remote-boot server is down. I wanna check mail! 12-01-99 > Tuesday I see a quite old message, he has managed to cut the size of DEPPTINY v0.3 down to 550 bytes. Maybe it's possible to fit under 513 bytes, but still I doubt it. He also sent me a pre-release BETA of aPACK. 13-01-99 Wednesday > As I found a bug on tested aPACK, I wrote Jibz about it and telling him I'm about to start my exams, so he shouldn't wait for my new DEPPTINY version to release aPLib. 15-01-99 > Friday > aPLib 0.20b has finally been released. Jibz has adapted my code to his syntax, and re-added the C conexion parts. No problem about it, after all, aPLib is HIS product, and this way the format is more regular. There's also a TASM version which work with BC. Examples still almost unchanged, he just updated the date from 1998 to 1998-99 But to my nasty surprise, the adapted routines are outdated, and my last core optimizations (3 bytes) were not added. I add them and also short some jumps in TASM version. I send corrections to him, but I'm not sure if he'll update it in v0.20b or in next release... 17-01-99 Sunday Can't resist the temptation. Take a look on DEPPTINY. Kill 9 bytes. Now it's 541. 18-01-99 Monday > Send new DEPPTINY to Jibz. 19-01-99 > Tuesday AAAAARRGH! He did it! Managed to reduce 29 bytes, leaving DEPPTINY with 512. Hurra! The only-one diskette sector size has been reached! This guy is really incredible... And core size has been reduced 5 more bytes... 27-01-99 Wednesday Oooops! DEPPTINY is buggy... It seems that last optimizations where a little bit too agressive. Urg! it's my fault!!!. It was my last 9 bytes killed!. Can't believe it and can't understand why it fails. Let's debug it... Ok I found my bug. Hop! Fixed. No penalty bytes. It's still 512. 28-01-99 Thursday > Send bugfixed DEPPTINY to Joergen. 15-02-99 Monday It has taken me three months to realize that DEPPACK and DEPPTINY were supporting drives and paths from the begining, despite what DEPPACK says in the usage message. How could I be SO stupid. 23-02-99 Tuesday Started porting last DEPPTINY optimizations to DEPPACK. It's getting harder than I thought. Killed 1 byte on DEPPTINY > 511. 24-02-99 Wednesday > Send the 511 one... Instead of looking to all optimizations and put and adapt the ones I can to DEPPACK, I've grown a new DEPPACK from last DEPPTINY, adding the error messages, but it can't handle "bad infile" detection as it was done with previous DEPPACK. It fails on the same way of DEPPTINY, and I'm not sure why DEPPTINY fails anyway... It's driving me insane!!! 25-02-99 Thursday > Send the new non perfect DEPPACK to Jibz. Let's see if he can find something about the mysterious bug. 1-03-99 Monday Kill another byte from DEPPTINY > 510. Gonna test it. Arg! Another pretty bug! Let's see... DEPPACK works right... 512-DEPPTINY works right 511-DEPPTINY fails... Strange. Oh, now I've seen it... Bugfixed. Ported the 5 bytes core optimizations to DEPACK16 routines, and cleaned 3 bytes from C connection part from them. 3-03-99 Wednesday > Send the bugfixed 510 DEPPTINY. 8-03-99 Tuesday > Removing those 3 bytes from C connection part wasn't such a good idea, but 1 of them at least can be safely removed. Re-send the non perfect DEPPACK. 9-03-99 > Wednesday Jibz spent 3 bytes to make DEPPTINY a bit safer (it was assuming that high part of ESP was always 0), and removed 6 more bytes from it. Now it's only 507, and better than previous ones. I think we could also spend one more byte to clear the direction flag, leaving it with 508. 11-03-99 Friday > Send the 508 one and this updated history till the entry before this one :-) 16-03-99 Tuesday Ported the last optimizations to my own C-less version of DEPACK16. Started to look again at DEPPACK. Let's start from old DEPPACK instead of growing it from DEPPTINY. I'm checking the good behaviour of the whole thing with every bit changed. It's a really frustrating job. 17-03-99 Wednesday I've isolated 3 test versions of DEPPACK, one of them detects the "bad infile" in the test file, another gives always the same result and the last one produces different results depending of previous memory state. Still I can't understand why it happens. 18-03-99 Thursday > Send the test files to Jibz. Let's see if we can find out what the hell is happening together. 21-03-99 Sunday I've finally find out a possible solution (with expensive 9 bytes fix) to detect bad infiles. Seems to work well. Ported it to the "grown from DEPPTINY" one. 22-03-99 Monday > Send the fix to Jibz. 24-03-99 Wednesday Ported the fix to DEPPTINY, removing another test to keep it under 512 (actually 511). Found a bug in DEPPACK Jibz advised me about a while ago. Let's debug it once again. Fixed. Let's make a major test of everything. Ooopss!! First file tested: new bug found. This one crashes the system, for both brand-new DEPPACK and DEPPTINY. Seems to happen when saving last part. Let's debug it again. Ok, fixed too. 25-03-99 Thursday > Send everything... Some files were corrupted, and I'm told that current version is 0.22 instead of 0.21. Make the changes and resend it all. 26-03-99 Friday It seems that a really strange bug now happens only under DOS and not under Windows, corrupting last part of a big test file. This version seems doomed. 6-04-99 Tuesday 3 more bytes from DEPPACK has been removed. Tomorrow I'll send it 27-04-99 Tuesday > Send DEPPACK and DEPPTINY to aPACK mail-list to see if someone knows what is happening. 26-05-99 > Wednesday aPLib 0.22b has finally been released. As it happened with 0.20, some files aren't updated. Jibz didn't respond about the strange bug when I asked him information in the mail-list, and there's no reference about it in the release. Maybe it wasn't DEPPACK problem after all. Tomorrow I'll send him newer versions of updated files. 28-05-99 > Friday > I've finally sent the updated files, and a silent update with those files has been made in Jibz's homepage. 1-06-99 > Tuesday Oleg Prokhorov has found the famous bug. Microsoft fault, because: wasn't DOS supposed to be a 16 bit O.S.? Then why the hell is it corrupting the high part of eax when calling an API function? The fix cost 2 bytes for each version, so it makes DEPPTINY grow to 513 (arg!). 3-06-99 Thursday I think we should sacrifice again the cld intruction in DEPPTINY to keep it in 512 13-07-99 Tuesday I've found 2 small mistakes in the files I sent for the updated version. DEPACK16.NAS claims to be v0.21b, and DEPACK16.ASM has a "adc ecx, ecx" instead the "adc cx,cx" it should have. (So TASM users get a 1 byte bigger version than NASM ones). Removed 8 bytes from DEPPACK. Now it's 954/878 bytes long. 15-07-99 Thursday > Send everything 20-07-99 > Tuesday Jibz has managed to cut 11 bytes from DEPPTINY!!!! Of course cld is welcomed again, leaving it in 502. 25-07-99 Sunday Ported Jibz's last optimizations to DEPPACK (941/873) and source codes, and added back the missing bad infile test to DEPPTINY (506). Oops! I changed the wrong "adc ecx,ecx" to "adc cx,cx", fixed. Tomorrow I'll send it. 2-09-99 Thursday Removed 1 byte from DEPPACK (940/872) 22-11-99 Monday 3 bytes removed from DEPPTINY (503: Getting near the 500 barrier...) and DEPPACK (937/833 -> Using Chut's 4C, algorithm 02). 24-11-99 Thursday The new 4C-02 v1.01 leaves DEPPACK at 832. 28-11-99 Monday The updated 16 bit depackers finally appear at Jibz's homepage. 29-02-00 Tuesday Removed 2 more bytes from DEPPTINY (501) and DEPPACK (935/827 -> Using Chut's 4C-02 version 1.00 alpha). Start commenting DEPPTINY a bit more... 2-03-00 Thrusday Removed another byte from both (500, 934/826). 4-03-00 Saturday And one more (499!, 933/826). I'm thinking about performing a memory test to check you actually have those 162K needed to run the programs. I guess 13 bytes are more than enough for DEPPTINY. 10-03-00 Friday Removed 2 more bytes from both again (497,931/822). 3-04-00 Monday Removed 2 VERY evident do-nothing bytes from DEPPACK (929/821). 4-04-00 Tuesday > Added memory check (7 bytes for DEPPTINY (504), 29 for DEPPACK (962/848)). Continue adding comments to DEPPTINY... and put'em in DEPPACK too. Now I feel it's small, safe and clear enough to raise the version to v0.9 (nearly perfect?). 5-04-00 > Wednesday Jibz cutted 2 bytes from core, and 6 more from DEPPACK's syntax text, leaving sizes of 502 for DEPPTINY and 954/841 for DEPPACK. Also, APLIB's version number has been increased to v0.26b.